\chapter{Motivation}\label{C:Motivation}

Although software does offer the benefits of added flexibility, increased
functionality, and reduced costs, it provides unprecedented possibilities for
errors. Safety-critical systems have been on the bandwagon of using software in
their implementations for some time \cite{Graupe78,Hurtig94}, and disputes have
since then occurred regarding their stability \cite{Leveson93,Maisel05}. The 
advent of such systems juxtaposed with the complexities of software breeds a new
set of concerns that do not easily map to traditional engineering standards.

Because of its unique nature, defects in software are inevitable and typically
more difficult to locate and handle than the physical flaws found in mechanical
components. Defects in software used in safety-critical situations can be
especially dangerous. The increasing use of software in machines and the demand
for more product functions adds complexity and more room for error. Models to
test, detect, and correct these errors exist and are continually improving
\cite{Parnas90}.

Since testing is a key phase for software quality assurance, it is a clear
target for scrutiny under a legal dispute.

\section{General Problem Statement}
What are some of the necessary social constraints for testing safety-critical
software and what standards or practices can software engineers use to fulfill
them?

\section{The Case of the Killer Robot}\label{killer}
``\textit{The Case of the Killer Robot}'' \cite{Epstein96} is a fictional  
scenario detailing software engineering with computer ethics that will be the
focus of observation in this paper. The hypothetical scenario consists of seven
newspaper articles, one journal article, and one magazine interview; each of
which are listed fully in Appendix \ref{A:Killer}. Section \ref{killerfacts}
summarizes the events that occured in the story.

\subsection{Facts}\label{killerfacts}

Silicon Techtronics, a software company in Silicon Valley, manufactured and
sold models of the Robbie CX30 industrial robot to several other companies. Each
robot is custom programmed to fit the needs of the client. Cybernetics Inc.
purchased a Robbie CX30 robot for use in its assembly line. A malfunction in the
robot's software caused its ``arm'' to flail violently, striking its operator,
Bart Matthews. The motion of the robot's arm threw him against a wall crushing
his skull and ultimately resulting in his death.

The defect was isolated to a specific piece of code written in the C programming
language by Silicon Techtronics programmer Randy Samuels. Jane McMurdock,
prosecuting attorney for the city of Silicon Valley, alleges that Samuels
``negligently misinterpreted'' a mathematical formula provided by the project
physicist when programming the software that controls the robot's arm motion. 
Though Samuels was indicted for manslaughter, other aspects of Silicon
Techtronics' operating procedures could have contributed to this defect and the
eventual incident resulting in Bart Matthew's death.

According to an anonymous Silicon Techtronics insider, the Robbie CX30 robot
project was rushed and company friction between management and engineering 
caused delays and new hirings of engineers. This friction, as confirmed by
Silicon Techtronics software tester Cindy Yardley, also compelled management to
pressure testers into fabricating software test results so the company could 
ship the robot sooner. The Robbie CX30 team also used the ``waterfall''
\cite{Royce70} process model rather than a ``prototyping'' model. This meant
that end users were not able to operate the machine until late in the process of
development. In addition, Ruth Witherspoon, spokesperson for the \textit{Justice
for Randy Samuels Committee}, alleges that Silicon Techtronic's quality 
assurance methods were ``lax'', and that the company did not adequately train
the operators of its robots as promised in the Robbie CX30 requirements
documentation. As a fail-safe, the User Interface (UI) of the Robbie CX30 robot
allows operators to halt the motion of the robot ``long before bodily injury can
actually occur''. But the sequence of commands to halt the robot were complex
and the UI was, according to UI expert Dr. Horace Gritty, culpable for having
caused the incident.

\subsection{Issues}

The scenario arouses several liability concerns. Is Samuels the sole culprit of
Matthews' death? How sound were the processes used to manage the project? Did
the test team make a ``fair'' tradeoff in their test fabrications? Was the
design adequate for what it was to be used for? The next chapters will reveal
more facts of the case and examine the issues related to testing in this
scenario in more detail.
